在前面幾天中，我們從底層的 Fiber 架構、Hooks 探索一路走到現代的 SSR 渲染範式。今天我們要來探討每個 React 專案啟動時都會遇到的問題：前端狀態管理（State Management），我們到底該怎麼選？

從早期龐大的 Redux、內建的 Context，到近年呼聲極高的 Zustand，這三種主流工具的底層運作邏輯與適用情境究竟是什麼？

一、 核心心智模型與比較

二、 三大方案深度剖析

1. React Context：它不是狀態管理器，它是「依賴注入」
   很多人誤以為 Context 是用來取代 Redux 的。事實上，Context 的本質是「避免 Props Drilling（屬性穿透）」的傳遞工具。

   • 致命缺點：一旦 Context Provider 的 value 物件發生變更，所有訂閱該 Context 的子孫組件無論有沒有用到該屬性，都會被強制觸發 Re-render。

   • 最佳實踐：僅適用於極少變動的全域屬性（如語系 locale、主題 theme、登入狀態 auth）。

2. Redux Toolkit (RTK)：大型團隊的標準化防護網
   老牌王者 Redux 經過 Toolkit 的重構後，已經擺脫了過去冗長的 Boilerplate 程式碼惡夢。

• 核心優勢：

  • Immer 內建支援：讓你用直覺的「可變寫法」去修改 State，底層自動幫你維護 Immutability。

  • 嚴格的狀態流向：Action ->Reducer -> Store，所有狀態變更都有跡可循，極適合多人協作的大型團隊。

  • DevTools 支援：強大的時間旅行除錯能力。

3. Zustand：現代 React 開發的輕量化新寵
   近年迅速崛起的 Zustand 採用了完全不同的設計哲學——不依賴 React Context，直接在 React 樹狀結構之外建立一個獨立的 Store。

• 核心優勢：

  • 極致簡潔：沒有繁瑣的 Provider 包裹，幾行程式碼就能搞定 Store 建立與綁定。

  • 精準 Selector 訂閱：組件只會因為它「實際用到的那個 State 屬性」改變才觸發 Re-render，完美避開了 Context 的效能陷阱。

// Zustand Store 建立範例，乾淨俐落
import { create } from 'zustand';

const useStore = create((set) => ({
  count: 0,
  increase: () => set((state) => ({ count: state.count + 1 })),
}));

// 組件中按需選取，絕不囉嗦
function Counter() {
  const count = useStore((state) => state.count);
  const increase = useStore((state) => state.increase);
  return <button onClick={increase}>Count: {count}</button>;
}

三、 選型決策指南：我們該怎麼選？

1. 優先評估是否需要全域狀態：

   • 80% 的狀態其實只需要放在區域組件 (useState) 或利用 State 下沉 即可解決，切勿過早引入全域狀態管理。

2. 小型專案或簡單共用：

   • 選擇 React Context（但記得拆分多個 Context 以降低影響範圍）。

3. 極致效能與輕量開發體驗：

   • 選擇 Zustand（當前多數中小型到中大型專案的首選）。

4. 大型企業級、強規範、複雜非同步中介軟體 (Middleware) 需求：

   • 選擇 Redux Toolkit (RTK)。